비제네릭 컬렉션

ArrayList는 .NET Framework 1.0에서 도입된 비제네릭 컬렉션 클래스로, System.Collections 네임스페이스에 속한다. 이 클래스는 크기가 동적으로 변하는 배열을 구현하며, 인덱스를 사용하여 목록의 요소에 접근할 수 있다. 내부적으로는 배열을 사용하여 요소를 저장하며, 요소가 추가되어 용량이 부족해지면 더 큰 배열을 새로 할당하고 기존 요소를 복사하는 방식으로 동작한다.

ArrayList는 모든 요소를 객체 타입으로 저장한다. 이는 값 형식의 데이터를 저장할 때 박싱이 발생하여 성능에 부정적인 영향을 미칠 수 있음을 의미한다. 또한 컬렉션에서 요소를 꺼낼 때는 원하는 실제 타입으로 명시적 형변환을 수행해야 하며, 잘못된 타입으로 변환을 시도하면 런타임 오류가 발생할 수 있어 타입 안정성이 보장되지 않는다.

주요 메서드로는 Add, Insert, Remove, RemoveAt 등이 있으며, Sort 메서드를 통해 목록을 정렬하거나 BinarySearch 메서드로 요소를 검색할 수 있다. .NET Framework 2.0에서 제네릭이 도입된 이후에는 타입 안전성과 성능 면에서 우수한 List<T> 클래스가 ArrayList를 대체하는 표준으로 자리 잡았다.

Hashtable은 .NET Framework 1.0에서 도입된 비제네릭 컬렉션의 핵심 클래스 중 하나로, 키-값 쌍을 저장하는 사전 구조를 제공한다. System.Collections 네임스페이스에 속하며, 내부적으로 해시 테이블 알고리즘을 사용하여 데이터를 저장하고 검색하기 때문에 빠른 조회 성능을 보인다. 모든 요소는 Object 타입으로 저장되며, 키와 값 모두 임의의 .NET 객체를 사용할 수 있다.

Hashtable의 주요 메서드로는 Add, Remove, ContainsKey, ContainsValue 등이 있다. Add 메서드를 사용하여 키와 값을 추가할 수 있으며, 동일한 키를 두 번 추가하려고 하면 예외가 발생한다. 데이터를 검색할 때는 인덱서를 통해 키를 지정하여 값을 가져오거나, foreach 루프와 DictionaryEntry 구조체를 사용하여 모든 항목을 순회할 수 있다.

이 클래스는 스레드 안전성을 고려하여 설계되었다. 여러 스레드에서 동시에 읽는 작업은 안전하지만, 하나의 스레드가 쓰기 작업을 하는 동안 다른 스레드에서 읽거나 쓸 경우 문제가 발생할 수 있다. 이러한 경우 Synchronized 정적 메서드를 통해 동기화된 래퍼를 생성하거나, 명시적인 락 메커니즘을 사용하여 동기화를 처리해야 한다.

Hashtable은 레거시 코드와의 호환성을 위해 여전히 지원되지만, 새로운 개발에는 제네릭 컬렉션인 Dictionary<TKey, TValue> 클래스를 사용하는 것이 권장된다. 제네릭 버전은 타입 안정성을 제공하고 박싱 및 언박싱 오버헤드를 제거하여 성능과 코드의 명확성을 모두 향상시킨다.

Stack 클래스는 LIFO(Last-In, First-Out, 후입선출) 방식으로 동작하는 비제네릭 컬렉션이다. 이 클래스는 System.Collections 네임스페이스에 포함되어 있으며, .NET Framework 1.0부터 제공된 레거시 자료 구조이다. 스택은 주로 실행 취소(Undo) 기능, 수식 평가, 재귀 알고리즘의 구현 등에 활용된다.

주요 메서드로는 Push(요소 추가), Pop(최상위 요소 제거 및 반환), Peek(최상위 요소 확인)이 있다. 모든 요소는 Object 타입으로 저장되므로, 값 형식을 저장할 경우 박싱이 발생하고, 요소를 꺼낼 때는 원하는 타입으로 명시적 형변환을 수행해야 한다. 이는 타입 안정성을 보장하지 못하고 성능 오버헤드를 유발할 수 있다.

제네릭이 도입된 이후에는 동일한 LIFO 구조를 제공하면서 타입 안전성을 갖춘 System.Collections.Generic.Stack<T> 클래스의 사용이 권장된다. 그러나 기존 레거시 코드를 유지보수하거나 .NET Framework 초기 버전과의 호환성이 필요한 경우에는 비제네릭 Stack 클래스가 여전히 사용된다.

Queue 클래스는 선입선출 방식으로 동작하는 비제네릭 컬렉션이다. 이 클래스는 객체 타입의 요소를 저장하며, .NET Framework 1.0부터 제공된 레거시 컬렉션이다. Queue는 데이터를 임시로 저장하고 순서대로 처리해야 하는 시나리오, 예를 들어 작업 대기열이나 메시지 큐 구현에 주로 사용된다.

주요 메서드로는 Enqueue 메서드를 사용하여 컬렉션의 끝에 요소를 추가하고, Dequeue 메서드를 사용하여 컬렉션의 시작 부분에서 요소를 제거하며 반환한다. 또한 Peek 메서드를 통해 제거하지 않고 시작 부분의 요소를 확인할 수 있다. 이 클래스는 내부적으로 순환 배열을 사용하여 구현되어 효율적인 입출력이 가능하다.

Queue 클래스는 모든 요소를 객체 타입으로 다루기 때문에, 값 타입을 저장할 경우 박싱이 발생하고 요소를 꺼낼 때는 명시적 형변환이 필요하다. 이로 인해 타입 안정성이 보장되지 않으며 잘못된 형변환 시 런타임 오류가 발생할 수 있다. 또한 박싱과 언박싱 과정에서 성능 오버헤드가 존재한다.

.NET Framework 2.0 이후로는 타입 안전성을 제공하는 제네릭 컬렉션인 System.Collections.Generic.Queue<T> 클래스가 도입되었다. 새로운 개발에는 Queue<T>를 사용하는 것이 권장되며, 기존 레거시 코드나 특정 호환성이 필요한 경우에만 비제네릭 Queue 클래스를 사용한다.

ICollection 인터페이스는 .NET Framework의 System.Collections 네임스페이스에 정의된 핵심 인터페이스이다. 이 인터페이스는 비제네릭 컬렉션의 기본 계약을 정의하며, 컬렉션의 크기, 열거 지원, 동기화 가능성과 같은 기본적인 기능을 제공한다. IEnumerable 인터페이스를 상속받아 컬렉션의 요소를 순회할 수 있는 능력을 확장한다.

ICollection 인터페이스는 Count, IsSynchronized, SyncRoot와 같은 주요 속성과 CopyTo 메서드를 정의한다. Count 속성을 통해 컬렉션에 포함된 요소의 수를 알 수 있으며, CopyTo 메서드는 컬렉션의 요소들을 배열로 복사하는 기능을 제공한다. IsSynchronized와 SyncRoot 속성은 멀티스레드 환경에서 컬렉션에 대한 스레드 안전한 접근을 관리하기 위한 메커니즘과 관련이 있다.

이 인터페이스는 ArrayList, Hashtable, Stack, Queue 등 System.Collections 네임스페이스의 대부분의 구체적인 컬렉션 클래스들이 구현한다. 이를 통해 다양한 컬렉션 타입에 대해 일관된 방식으로 크기 확인이나 배열 복사와 같은 기본 작업을 수행할 수 있는 기반을 마련한다. 그러나 요소의 추가나 제거와 같은 수정 작업에 대한 계약은 포함하지 않는다.

제네릭 컬렉션이 도입된 이후에는 보다 타입 안전하고 성능이 우수한 ICollection<T> 인터페이스가 주로 사용된다. ICollection 인터페이스는 주로 레거시 코드를 유지보수하거나 .NET Framework 초기 버전과의 호환성이 필요한 상황에서 마주치게 된다.

비제네릭 컬렉션의 가장 큰 문제점은 타입 안정성이 보장되지 않는다는 점이다. System.Collections 네임스페이스의 ArrayList나 Hashtable과 같은 클래스들은 모든 요소를 Object 타입으로 저장한다. 이는 컬렉션에 어떠한 타입의 객체도 추가할 수 있게 하지만, 반대로 컬렉션에서 요소를 꺼낼 때는 원래의 타입으로 명시적인 형변환을 수행해야 한다.

이 과정에서 잘못된 타입으로의 형변환이 시도되면 런타임에 InvalidCastException 예외가 발생한다. 예를 들어, 문자열만 저장하려던 ArrayList에 실수로 정수를 추가하고, 이를 꺼내어 문자열로 변환하려고 하면 프로그램이 실행 중에 오류로 중단될 수 있다. 이러한 오류는 컴파일 타임에는 검출되지 않기 때문에 디버깅이 어렵고 프로그램의 신뢰성을 떨어뜨린다.

또한, 개발자가 의도한 데이터 타입만 저장하도록 주의를 기울여야 하므로, 코드의 의도를 명확히 표현하기 어렵고 실수할 가능성이 높아진다. 이는 대규모 협업 프로젝트나 유지보수 단계에서 특히 큰 문제가 될 수 있다.

비제네릭 컬렉션은 모든 요소를 객체 타입으로 저장한다. 이는 값 형식 데이터를 컬렉션에 추가할 때 박싱이 발생함을 의미한다. 박싱은 값 형식을 힙 메모리에 할당된 참조 형식인 객체로 변환하는 과정으로, 추가적인 메모리 할당과 복사 작업을 수반한다.

반대로 컬렉션에서 값을 꺼내 사용할 때는 언박싱이 필요하다. 언박싱은 객체 참조를 원래의 값 형식으로 다시 변환하는 과정이다. 이 과정에서 형식 검사와 데이터 추출 작업이 발생하며, 잘못된 형변환 시 예외가 발생할 수 있다.

이러한 박싱과 언박싱은 반복적으로 수행될 경우 성능에 영향을 미칠 수 있다. 특히 대량의 데이터를 처리하거나 빈번한 접근이 필요한 시나리오에서는 가비지 컬렉션의 빈도를 증가시키고 CPU 연산 오버헤드를 유발할 수 있다. 이는 제네릭 컬렉션이 값 형식을 그대로 저장하여 이러한 오버헤드를 제거하는 것과 대비되는 특징이다.

비제네릭 컬렉션에서 요소를 꺼낼 때는 반드시 명시적 형변환이 필요하다. System.Collections 네임스페이스의 ArrayList나 Hashtable과 같은 클래스들은 모든 요소를 Object 타입으로 저장하기 때문이다. 컬렉션에서 값을 가져오는 순간, 컴파일러는 그것이 단순한 Object라고만 인식하므로, 개발자가 원래 저장했던 실제 타입(예: String이나 Integer)으로 변환해 주어야 한다.

이 과정은 코드에 불필요한 형변환 연산자를 추가하게 만들며, 가독성을 떨어뜨린다. 예를 들어, 정수형 리스트에서 값을 꺼내려면 int value = (int)arrayList[0];과 같이 캐스팅을 수행해야 한다. 이는 제네릭 컬렉션을 사용할 때와 비교해 코드가 더 장황해지는 주요 원인이다.

더 큰 문제는 이 형변환이 런타임에 실행된다는 점이다. 컴파일 시점에는 타입 불일치 오류를 잡아낼 수 없어, 잘못된 타입으로 캐스팅을 시도하면 InvalidCastException이 발생할 위험이 항상 존재한다. 이는 타입 안정성을 보장하지 못하는 비제네릭 컬렉션의 근본적인 한계를 보여준다. 따라서 레거시 코드를 유지보수하거나 특별한 호환성 이유가 없는 한, 제네릭 컬렉션을 사용하여 이러한 명시적 형변환과 관련된 문제를 피하는 것이 바람직하다.